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(S) System and method for monitoring simple network management protocol tables. 



(57) A new system and method allows a Manager 
in a Simple Network Management Protocol 
(SNMP) environment to gather updates from its 
Agents. The system and method comprise the 
unique provision of an index which is used in 
each of the Agent's tables for indicating the 
various revisions thereof. The index 
lexicographically increases with each revision 
to the table. The Manager maintains a record of 
the index of the data which it has received from 
its Agents, requesting only that data having a 
lexicographically larger indexing. Further, the 
index is used in related tables so that the tables 
will be kept in "sync" in that the Manager will 
know whether it has the latest updates so that 
an accurate picture may be portrayed. 




3! 




CM 
<0 



LU 



Jouvo. 18. rue Saint-Denis, 75001 PARIS 



1 



EP 0 621 706 A2 



2 



BACKGROUND OF THE INVENTION 

I. Field of the Invention 

The present invention relates to network man- 
agement using the Simple Network Management 
Protocol (SNMP) and, more particularly, to a system 
and method for monitoring SNMP tables. 

II. Background and Prior Art 

Data communication has become a fundamental 
part of computing. World-wide networks gather data 
about such diverse subjects as atmospheric condi- 
tions, crop production, and airline traffic. These net- 
works evolved as independent entities without the 
ability, or, until recently, the need, to interconnect 
with one another. New technologies, genetically 
named "internetworking", have emerged making it 
possible to interconnect many disparate physical net- 
works and make them function as a coordinated unit. 
Using internetworking technologies, a host, for exam- 
ple, on one network, may traverse multiple networks 
and communicate with another host on a different 
network. 

The size of an "internet", or group of interconnect- 
ed networks, can vary quite significantly. For in- 
stance, the resulting network may be enormously 
large, such as the nation-wide DARPA (Defense Ad- 
vanced Research Projects Agency)/NSF (National 
Science Foundation) Internet which connects most 
major research institutions, including universities, 
corporate and government labs. Conversely, the net- 
work may be relatively small, characterized in that it 
comprises only a single corporation's individual local 
area networks (LANs). 

No matter the size of the network, it is clear that 
the task of effectively managing the resulting inter- 
connected network is quite important and has been 
given a great deal of attention in the networking com- 
munity. In managing a network, a network manager 
must keep track of the devices on the networks, mon- 
itor the network's performance and load, and diag- 
nose and correct any problems. 

While products that manage homogeneous net- 
works have been available, managing heterogene- 
ous networks is more complex and, until recently, no 
generally accepted heterogeneous network manage- 
ment standard existed. The Simple Network Manage- 
ment Protocol (SNMP), which originated as a means 
for managing the TCP/IP (Transmission Control Pro- 
tocol/Internet Protocol) and Ethernet networks, has 
broadened rapidly since its monitoring and control 
transactions are completely independent of TCP/IP 
and Ethernet. 

Using SNMP, network administrators can ad- 
dress queries and commands to network nodes and 
devices. SNMP monitors network performance and 



status; controls operational parameters; and reports, 
analyzes and isolates faults. The protocol accom- 
plishes these functions by transporting management 
information between "Managers" and "Agents". 
5 SNMP defines the following three basic compo- 

nents: 1. An Agent, a component housed within a 
managed network device such as a host, gateway, or 
terminal server. Each Agent stores management data 
and responds to the Manager's requests for this data, 
10 and may send a "TRAP", a special unsolicited SNMP 
message, to the Manager after sensing a prespeci- 
fied condition. 2. A Manager, a component housed 
within a Network Management Station. The Manager 
queries/controls Agents using various SNMP com- 
15 mands. 3. A Management Information Base (MIB), a 
managed object database, accessible to Agents and 
manipulated via SNMP for network management ap- 
plication. 

To carry out the Agent's and Manager's duties, 
20 SNMP specifies five types of commands or verbs, 
called Protocol Data Units (PDUs): GetRequest, Get- 
NextRequest, SetRequest, GetResponse and Trap. 
Agents inspect and retrieve the management data af- 
ter receiving either a GetRequest or a GetNextRe- 
25 quest PDU from a Manager. Managers use GetRe- 
quest for retrieving single values of the managed ob- 
jects. The GetNextRequest is issued by the Manager 
to begin a primitive block transfer and the Agent re- 
turns the selected data with a GetResponse verb. 
30 Managers use SetRequest commands for instructing 
Agents to alter MIB variables while Traps are unsoli- 
cited messages sent by Agents to Managers after 
sensing prespecif ied conditions. 

SNMP managed objects are logically grouped. 
35 For example, MIB II, the current Internet standard 
MIB, defines the following logical groups: system, in- 
terfaces, at, ip, icmp, tcp, egp, transmission, and 
snmp. Some of these groups are optional and may or 
may not be present in an SNMP managed device, de- 
40 pending upon the device's capability, i.e., if a device 
is performing exterior gateway protocol (egp) routing, 
the group must be present. Other, proprietary groups 
of objects can be created by following the proper reg- 
istration scheme. 
45 The Manager is charged with, among other 

things, monitoring network performance and status, 
controlling operational parameters, and reporting, 
analyzing and isolating faults in its managed domain. 
In order to effectively accomplish these functions, the 
so Manager requires precise and timely data regarding 
the network and the nodes in the network. 

Figure 1 illustrates a simplified network having 
four interconnected nodes, Node 1, Node 2, Node 3 
and Node 4. The nodes are logically interconnected 
55 by transmission groups (TGs). As can be seen, Node 
1 is connected to Node 2 by TG A, Node 1 to Node 4 
by TG E, and so forth. Each node is a managed net- 
work device in the SNMP sense and has an Agent for 
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storing management data and for responding to the 
Manager, which is logically connected to each Agent. 
The management data in this case may include node 
characteristics, such as its name, type, uptime, level 
of service, etc., as well as TG characteristics, such as 
owner of the TG, destination of the TG, whether the 
particular TG is presently operational, etc. In this 
case, some of the node characteristics data are inter- 
related to some of the TG characteristics data. For in- 
stance, if a new node is added to the network, it would 
be reflected in the node characteristics data. Like- 
wise, new TGs would be reflected in the TG charac- 
teristics data as any new TG connects to the node. 

Using present management systems and meth- 
ods, the Manager periodically polls its Agents using 
GetNextRequest PDUs for receiving the managed ob- 
jects maintained by the Agents. For example, a Man- 
ager may need to provide a graphical user interface 
(GUI) depicting a network map. The Manager initially 
polls each Agent using GetNextRequest PDUs for re- 
trieving each respective Agent's entire managed ob- 
ject table(s) until all of the data is retrieved for building 
the network map GUI. Subsequently, after some of 
the conditions may or may not have changed, the 
Manager repeats the process of polling the Agents to 
retrieve their respective entire managed object ta- 
blets) so that changed conditions may be noted. Fig- 
ure 2 illustrates the traditional table retrieval where 
the Manager issues a series of GetNextResponse 
commands to the Agent which responds with corre- 
sponding GetResponse messages along with the re- 
quested data. For example, when the Manager issues 
a GetNextRequest (lndex=FIRST) PDU, the Agent re- 
sponds with a GetResponse (Index = FIRST + 1 ) PDU 
along with the requested record. This process is re- 
peated until an "End of Table" response is received by 
the Manager. After the Manager waits a predeter- 
mined time, it duplicates this process and again re- 
trieves the entire managed object table(s). 

Some of the managed objects are quite dynamic 
but there is no present mechanism for retrieving only 
the changed objects - rathereach Agents entire man- 
aged object table(s) must be retrieved forcing the 
Manager to sort through the relevant and irrelevant 
data. This strategy is deemed unacceptable from 
both a useability and a performance perspective as 
the overhead of re-processing the entire table(s) of 
thousands of entries severely impacts the perfor- 
mance of the network, Agent and Manager. 

Figure 3 illustrates a traditional method of receiv- 
ing change/update notifications. This method of indi- 
cating to the Manager that a change has occurred in 
an Agent's managed object database is done by hav- 
ing the Agent issue an unsolicited Trap PDU with the 
changed data. This strategy is deemed unacceptable 
from a reliability perspective as an update may never 
reach the Manager - and/or cannot be controlled by 
the Manager. 



Further, many times, groups of managed objects 
are interrelated so that when an object in one group 
changes, one or more corresponding objects in an- 
other group may need to be subsequently changed. 

5 (The node and TG tables, each previously described, 
are an example of this situation.) 

Clearly, these interrelated tables need to be in 
"sync" from the Manager's perspective, that is, the 
Manager needs to have the latest updates for each of 

10 the tables in order to have an accurate picture of the 
network. If the tables are not in sync, the Manager's 
network map depicted by the GUI could, for instance, 
show TGs extending into space having no destination 
nodes or, alternatively, could show nodes having no 

15 interconnecting TGs. 

Presently, there is no mechanism for allowing the 
Manager to effectively maintain views of its tables 
which are consistent with those of the Agents. 

20 SUMMARY OF THE INVENTION 

A new system and method allows a Manager in a 
Simple Network Management Protocol (SNMP) en- 
vironment to gather updates from its Agents. The sys- 

25 tern and method comprise the unique provision of an 
index which is used in each of the Agenf s tables for 
indicating the various revisions thereof. The index 
lexicographically increases with each revision to the 
table. The Manager maintains a record of the index of 

30 the data which it has received from its Agents, re- 
questing only that data having a lexicographically 
larger indexing. Further, the index is used in related 
tables so that the tables will be kept in "sync" in that 
the Manager will know whether it has the latest up- 

35 dates so that an accurate picture may be portrayed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the technical description concludes with 
40 claims particularly pointing out and distinctly claim- 
ing that which is regarded as the invention, details of 
a preferred embodiment of the invention may be more 
readily ascertained from the following technical de- 
scription when read in conjunction with the accompa- 
45 nying drawings, where: 

Fig. 1 is a block diagram of a representative com- 
munications network within which the present inven- 
tion may be practiced. 

Fig. 2 depicts a flow diagram showing traditional 
so SNMP table retrieval using GetNextRequest and Ge- 
tResponse PDUs between a Manager and an Agent. 

Fig. 3 depicts a flow diagram showing a tradition- 
al SNMP change/update mechanism between an 
Agent and a Manager using an SNMP Trap PDU. 
55 Fig. 4 depicts a record of the type stored by the 

SNMP Agent of the present invention. 

Fig. 5 depicts another record of the type stored 
by the SNMP Agent of the present invention. 



VJSDOCID: <EP 0621706A2 I > 



EP 0 621 706 A2 



Fig. 6 is a flow diagram showing the flow of mes- 
sages between a Manager and an Agent of the pres- 
ent invention. 

Fig. 7 is a flow diagram performed at the Manager 
for retrieving an initial table and subsequent record 
updates. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 
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The method of the present invention is utilized in 
a system conforming to the Simple Network Manage- 
ment Protocol (SNMP). In such a system, an SNMP 
Manager can address queries and commands to 
Agents responsible for monitoring network nodes and is 
devices. The Manager monitors network perfor- 
mance and status; controls operational parameters; 
and reports, analyzes and isolates faults in Its man- 
aged domain. Using the present invention, the Man- 
ager initially queries its Agents using GetNextRe- 20 
quest PDUs to retrieve the managed objects main- 
tained by the Agents to obtain the initial status of the 
network. Subsequently, because the Agents use an 
indexing system which uniquely identifies record up- 
dates, the Manager merely polls the Agents for the 25 
updates using the last index from the previous retriev- 
al. This process reduces the overhead of re- process- 
ing the entire table(s) of thousands of entries which 
would severely impact the performance of the net- 
work, Agent and Manager. 30 

The method of the present invention can best be 
described in the context of a communications network 
having a plurality of network nodes, each network 
node maintaining its own tables defining managed 
objects and, in addition, having update information 35 
therein. In particular, the invention can be implement- 
ed in a system as described in commonly assigned U. 
S. Patent No. 5,1 01 ,348 relating to a method of reduc- 
ing the amount of information included in topology da- 
tabase update messages between network nodes in 40 
a communications network. In such a system, each 
network node maintains its own list of network re- 
sources in a topology database. When the state of a 
resource "owned" by a particular node changes, the 
node broadcasts a topology database update (TDU) 45 
message to the adjacent nodes. Each adjacent node 
updates its own topology database and rebroadcasts 
the message. To minimize the amount of information 
that must be included in TDU messages when two 
nodes are reconnected after an outage, each node so 
assigns flow reduction sequence numbers (FRSNs) 
to TDU messages and keeps a record of the FRSN for 
the last TDU message sent to an adjacent node. The 
node also records, for each resource in its database, 
the FRSN of the last TDU message including that re- 55 
source. When two nodes are reconnected after an 
outage, for example, the sending node includes in the 
TDU message only those resources having a FRSN 



greater than the FRSN assigned to the last TDU sent 
to the adjacent node to which the TDU message is di- 
rected. 

The method of the present invention uniquely 
takes advantage of the information stored in the net- 
work nodes of the described system. Specifically, the 
Agents for each SNMP managed device maintain the 
managed objects and utilize FRSNs in building the in- 
dex for the managed objects in its tables so that 
changes to the tables can be identified and only the 
updates are requested by the Manager after an initial 
retrieval of the managed objects is completed. In 
other words, along with each managed object a 
FRSN (in this case) is included as part of the index in 
order to identify the revision level of the object. 

Resource records of the types stored in the node 
characteristics table and of the transmission group 
(TG) characteristics table are shown in Figure 4 and 
Figure 5, respectively. For instance, each node re- 
cord 30 is made up of a flow reduction sequence num- 
ber (FRSN) field 32, a node name field 34, and a plur- 
ality of attributes fields 36 for storing the particular 
node characteristics which are being managed such 
as its type, level of service, etc. The FRSN and node 
name (or "FRSN.NodeName") are used to index the 
record to differentiate it from the remaining records in 
the database. Likewise, each TG record 40 is made 
up of an FRSN field 42, an origin node field 44, a des- 
tination node field 46, a TG name field 48 and a plur- 
ality of attributes fields 49 for storing the managed TG 
attributes, such its cost security level, eta The TG re- 
cord is indexed using the FRSN field 42, the origin node 
field 44, the destination field 46 and the TG name field 
48 (or "FRSN.OriginNode.DestNode.TGName") there- 
by assigning it a unique index per record. 

The Agent of the managed network device builds 
node and TG tables with these records. For example, 
initially, the Agent is able to build its node and TG ta- 
bles using the information that it has available to it re- 
garding the managed objects for which it is responsi- 
ble. Subsequently, each time a node receives updat- 
ed information in the form of a TDU from one of Its ad- 
jacent nodes, the updated information, as well as the 
FRSN assigned by this Agent, is recorded in the re- 
spective table by the Agent In this manner, the tables 
include not only the present status of the managed 
objects but in addition a running history of the object 
changes. The Manager merely has to retrieve the ini- 
tial table(s) and to periodically retrieve the table up- 
dates in order to consistently maintain an accurate 
network picture. 

The Manager is able to retrieve these records us- 
ing GetNextRequest PDUs as defined by SNMP. As 
discussed above, the GetNextRequest command re- 
trieves the next following object from the object spe- 
cified. The GetNextRequest verb is particularly use- 
ful in update retrieval where the GetNextRequests 
are based upon the index where part of the index re- 
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fleets incremental updates to the table and only the 
record updates are obtained. Where no updates have 
occurred, an "End of Table" response is returned. 
This response is actually the next object in the MIB 
tree or a "noSuchName" response. 

Figure 6 illustrates the message flow between an 
SNMP Manager and an Agent where the Manager is 
initially retrieving a table and subsequently retrieving 
updates to the table. In order to retrieve the initial ta- 
ble, the Manager issues a GetNextRequest having a 
NULL index to the Agent The Agent responds with the 
entry corresponding to the first index of the table. The 
Manager continues to issue GetNextRequests until 
an "End of Table" response is returned by the Agent. 
The Manager then stores the last index (LASTJ ) re- 
turned by the Agent; and waits for some given period 
of time. When the predetermined time interval has ex- 
pired, the Manager issues a GetNextRequest using 
the last index returned by the Agent (LAST^I). The 
Agent will then return only updates to the table, if any 
have occurred, or an "End of Table" response. Thus, 
only table updates or an "End of Table" response is re- 
turned to the Manager in response to subsequent 
GetNextRequests. 

Figure 7 illustrates the general logic flow used by 
the Manager in monitoring and synchronizing two ta- 
bles such as the Agent's node and TG tables. The 
Manager, beginning at 70, proceeds to retrieve node 
table updates, at 71 , from the Agent. If the Agent re- 
turns a node update in response to the Manager's re- 
quest, at 72, the manager performs another retrieve 
node update at 71 . When the Agent does respond with 
an "End of Table" message to the node update re- 
quest, the Manager proceeds to retrieve a TG update, 
at 73 from the Agent If the Agent returns a TG update 
in response to the Manager's request, at 74, the Man- 
ager performs another retrieve TG update at 73. 
When the Agent responds with an "End of Table" mes- 
sage to the node update request, the Manager pro- 
ceeds to retrieve a node update, at 75, from the 
Agent If the Agent returns a node update in response 
to the Manager's request, at 76, the Manager repeats 
this sequence again beginning at 71 . If the Agent re- 
turns an "End of Table" response, at 76, the process 
is complete; and the two tables are in "sync". 

Although not shown in Figure 7, the Manager log- 
ic would normally include a retry test and a consisten- 
cy test The retry test would be executed after at- 
tempting to retrieve a node table update, at 71 and 75, 
and after attempting to retrieve a TG table update at 
73. This retry test would be performed to handle the 
case where the Agent did not respond to the Man- 
ager's request due to some error condition such as 
the request or response was lost In the network. Sim- 
ilarly, the consistency test would be performed to in- 
sure that the Agent was not re-started between the 
time the Agent last responded and the Manager is- 
sued the next request This test could be based upon 



the Agent's uptime. If the Agenf s uptime was incon- 
sistent (less than that provided in the last response), 
the Manager would discard the Agent's previous re- 
sponse data and commence the process from the 
5 start. 

The method and system described allow an 
SNMP Manager to retrieve an initial picture of the sta- 
tus of specified managed objects and to monitor the 
status of those objects with minimal message flow 

10 between the Manager and the Agent. The reduction 
of message flow between the Manager and Agent al- 
lows the network to perform optimally as it is not satu- 
rated with network management message flows. The 
method and system of the present invention have 

is been described in terms of a system having network 
nodes each maintaining its own list of network re- 
sources in a topology database and utilizing an index 
which reflects updates to the table. The present in- 
vention is not specifically directed at this type of sys- 

20 tern, however, and may be implemented using any 
type of index number where a lexicographically larger 
index indicates an update. 

This system and method has significant advan- 
tages over traditional retrieval systems and method- 

25 ologies. It can provide significant performance bene- 
fits to the network, Agent and Manager. It can provide 
an atomic snapshot of a table at a given point in time. 
It can provide synchronization between multiple ta- 
bles. 

30 The system and method of the present invention 

also has advantages over traditional Trap methods. It 
can be controlled by the Manager and insures the de- 
livery of updates. 

35 

Claims 

1 . For use in a Manager of a network conforming to 
the Simple Network Management Protocol 
40 (SNMP) comprising at least one Agent, said 

Agent maintaining at least one table comprising 
individual records defining one or more individual 
managed objects, each individual record having 
a unique index assigned thereto, a method of 
45 monitoring said table characterized in that it com- 

prises the steps of: 

requesting from said Agent said individual 
records for said managed objects; 

receiving from said Agent said individual 
so records for said managed objects; 

maintaining a record of said index of the 
most recently received record for each managed 
object; and 

periodically requesting from said Agent 
55 the next record for each managed object as indi- 

cated by said index of the most recently received 
record for each managed object, said next record 
having an index lexicographically larger than the 
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index of said most recently received record for 
each managed object. 

2. The method defined in Claim 1 characterized in 
that it comprises, after said periodically request- 
ing step, the steps of receiving a next record for 
a managed object and maintaining a record of 
sard lexicographically larger index. 

3. The method defined in Claim 1 or 2 wherein said 
network comprises a plurality of nodes and a cor- 
responding plurality of Agents, each of said 
Agents maintaining a node characteristics table 
and a transmission group characteristics table. 

4. For use in an Agent in a network having a plurality 
of nodes, said network conforming to the Simple 
Network Management Protocol (SNMP), a meth- 
od of maintaining a table comprising individual re- 
cords defining one or more individual managed 
objects, characterized in that it comprises the 
steps of: 

maintaining an initial table of individual re- 
cords representing the initial status of said one or 
more individual managed objects, each of said 
records having an index; and 

adding to said initial table a further individ- 
ual record representing a changed status of one 
of said individual managed objects, said further 
additional record having a lexicographically larg- 
er index than the initial said one of said individual 
managed objects. 

5. In a network conforming to the Simple Network 
Management Protocol (SNMP) comprising at 
least one Agent, said Agent maintaining at least 
one table comprising individual records defining 
one or more individual managed objects, each in- 
dividual record having a unique index assigned 
thereto, a Manager for monitoring said table char- 
acterized in that it comprises: 

means for requesting from said Agent said 
individual records for said managed objects; 

means for receiving from said Agent said 
individual records for said managed objects; 

means for maintaining a record of said in- 
dex of the most recently received record for each 
managed object; and 

means for periodically requesting from 
said Agent the next record for each managed ob- 
ject as indicated by said index of the most recent- 
ly received record for each managed object, said 
next record having an index lexicographically 
larger than the index of said most recently re- 
ceived record for each managed object. 

6. The Manager defined in Claim 5 characterized in 
that it comprises means for receiving a next re- 
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cord for a managed object and means for main- 
taining a record of the index of said next record. 

The Manager defined in Claim 5 or 6 wherein said 
network comprises a plurality of nodes and a cor- 
responding plurality of Agents, each of said 
Agents maintaining a node characteristics table 
and a transmission group characteristics table, 
said Manager characterized in that it comprises 
means for receiving the records of said tables and 
means for periodically polling said Agents for up- 
dates to said tables. 

In a network having a plurality of nodes, said net- 
work conforming to the Simple Network Manage- 
ment Protocol (SNMP), an Agent for maintaining 
a table comprising individual records defining one 
or more individual managed objects character- 
ized in that it comprises: 

means for maintaining an initial table of in- 
dividual records representing the initial status of 
said one or more individual managed objects, 
each of said records having an index; and 

means for adding to said initial table a fur- 
ther individual record representing a changed 
status of one of said individual managed objects, 
said further additional record having a lexico- 
graphically larger index than the initial said one of 
said individual managed objects. 

The Agent defined in Claim 8 characterized in 
that it comprises means for receiving requests 
from a Manager for retrieving one or more of said 
individual records and for forwarding said records 
to said Manager. 

The Agent defined in Claim 8 or 9 characterized 
in that it comprises means for maintaining a plur- 
ality of tables including a node characteristics ta- 
ble and a transmission group characteristics ta- 
ble. 
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ronment to gather updates from its Agents. The system 
and method comprise the unique provision of an index 
which is used in each of the Agent's tables for indicating 
the various revisions thereof. The index lexicographically 
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maintains a record of the index of the data which it has 
received from its Agents, requesting only that data hav- 
ing a lexicographically larger indexing. Further, the index 
is used in related tables so that the tables will be kept in 
"sync" in that the Manager will know whether it has the 
latest updates so that an accurate picture may be por- 
trayed. 
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